home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1993
/
Internet Info CD-ROM (Walnut Creek) (1993).iso
/
inet
/
internet-drafts
/
draft-moore-mime-delivery-00.txt
< prev
next >
Wrap
Text File
|
1993-09-17
|
16KB
|
488 lines
Network Working Group Keith Moore
Internet Draft University of Tennessee
16 September 1993
MIME Content-Types
For Delivery Status Notifications
draft-moore-mime-delivery-00.txt
1. Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, and
its Working Groups. Note that other groups may also distribute working
documents as Internet Drafts.
Internet Drafts are valid for a maximum of six months and may be
updated, replaced, or obsoleted by other documents at any time. (The
file 1id-abstracts.txt, available via anonymous ftp from nic.ddn.mil,
describes the current status of each Internet Draft.) It is not
appropriate to use Internet Drafts as reference material or to cite them
other than as "work in progress".
2. Abstract
This memo defines a message format which may be used by a message
transfer agent (MTA) or internetwork mail gateway to report the result
of an attempt to deliver a message to one or more recipients. The
message format utilizies several MIME content-types which are also
defined by this memo.
3. Introduction
The SMTP protocol [1] requires that an SMTP server provide
notification of delivery failure, if it determines that a message cannot
be delivered to one or more recipients. Traditionally, such
notification consists of an ordinary Internet mail message (in the
format defined by [2]), sent to the envelope sender address (supplied
with the SMTP MAIL command), containing a human-readable explanation of
the error, and at least the headers of the failed message.
Experiences with large mail distribution lists [3] indicates that
such messages are often insufficient to diagnose problems, or even to
determine at which host or for which recipients a problem occurred. In
addition, the lack of a standardized format for delivery notifications
in Internet mail makes it difficult to exchange such notifications with
other message handling systems.
This memo defines a MIME [4] based protocol for delivery status
notifications (DSNs) in Internet mail. This protocol can be used to
notify the sender of a message of any of several conditions: successful
K. Moore Expires 16 March 1994 [Page 1]
Delivery Status Notifications 16 September 1993
delivery, failed delivery, message forwarding, or the gatewaying of a
message into an environment that may not support DSNs.
NOTE: A Delivery Status Notification (DSN) is different from a
Receipt Notification (RN). A DSN is issued by the mail transport
system, and indicates whether a message was successfully delivered to a
recipient's mailbox. A DSN conveys no information about what happens to
the message after it has reached the mailbox. An RN is issued by a
recipient's mail reader or message store, and conveys information about
whether a message has been read by the recipient.
This memo defines the format of a DSN. An extension to the SMTP
protocol to request DSNs is the subject of another memo [5]. Neither of
these protocols support receipt notifications. As of this writing,
protocols for RNs and requests-for-RNs is are yet to be defined.
4. The multipart/delivery-status-notification MIME content-type
The multipart/delivery-status-notification content-type is defined as
follows:
MIME type name: multipart
MIME subtype name: delivery-status-notification
Required parameters: same as in multipart/mixed
Optional parameters: none
Encoding considerations: same as in multipart/mixed
Security considerations: see section 7 of this memo.
The multipart/delivery-status-notification content-type is to be used
as the top-level content type for any DSN. This content-type up to
three sub-parts, in the following order:
(1) [required] A text/plain body part containing explanatory text.
This text may be in any MIME-standard charset.
(2) [required] A message/delivery-report body part containing the
details of the failed or successful delivery.
(3) [optional] A message/rfc822-fragment body part containing the
returned contents.
If the "returned contents" body part is present, a Content-ID header
should be associated with this body part, and the "returned-content"
parameter of the message/delivery-report body part should indicate the
content-id of the returned contents.
K. Moore Expires 16 March 1994 [Page 2]
Delivery Status Notifications 16 September 1993
5. The message/delivery-report MIME content-type
The message/delivery-report content-type is defined as follows:
MIME type name: message
MIME subtype name: delivery-report
Required parameters: none
Optional parameters: id, returned-content, charset
Encoding considerations: Any content-transfer-encoding may be
used. 7BIT is recommended unless an
alternate charset is required; otherwise,
use an appropriate encoding for that
charset.
Security considerations: discussed in section 7 of this memo.
The "id" parameter contains the envelope message-id of the message
for which the report is being generated (which may or may not be the
same as the message-id header).
If the message containing the delivery-report contains the returned
message, the "returned-content" parameter specifies the MIME content-id
of that message. If no "returned-content" parameter is supplied, the
content is not returned.
The "charset" parameter is optional. If it appears, it applies only
to the "text" fields of the delivery-report, and only if these fields
are written using the "alternate charset" mechanism defined by STIF. At
any rate, such charsets must be registered for use with the MIME
"text/plain" body part type.
The body of the delivery-report consists of one or more (per-
recipient) records formatted according to STIF [6]. Each record
consists of the following fields:
orig-rcpt The Internet mail address of the recipient, as originally
specified by the sender. [optional]
rcpt The electronic mail address of the recipient, from the message
envelope presented to the MTA or gateway issuing the report.
[required if orig-rcpt is not present]
mta The Internet domain name of the MTA or gateway generating the
report. For MTAs and gateways not on the Internet, a unique
name that reflects the location of the MTA or gateway may be
used. [required]
date The date of the delivery attempt, in RFC 822 "date-time"
format. [required for "delivered", "relayed", or "forwarded"
reports, optional for "failed" reports]
K. Moore Expires 16 March 1994 [Page 3]
Delivery Status Notifications 16 September 1993
action One of "delivered", "failed", "relayed", or "forwarded".
[required]
An action value of "delivered" indicates that the message has
been successfully delivered to the recipient address specified
by the sender. (This includes "delivery" to a distribution
list expander.)
A value of "failed" indicates that the message could not be
delivered to the recipient.
A value of "relayed" indicates that the message has been
relayed or gatewayed into an environment that does not
accepted responsibility for generating delivery reports that
conform to this specification.
A value of "forwarded" indicates that the message has been
delivered to the recipient address as specified by the sender,
and forwarded beyond that destination to one or more
additional addresses.
The keywords "delivered", "failed", "relayed", and "forwarded"
may be spelled in any combination of upper and lower case
characters.
status A 3-digit SMTP reply-code, indicating the delivery status for
that recipient. Normally this will be the reply-code returned
by an SMTP server in response to a RCPT command. Reply-codes
are defined in [1], [5], [7], [8], and other SMTP service
extension documents. If none of these reply codes is
appropriate, any of "200", "400", or "500" may be used to
indicate success, "temporary" failure, or "permanent" failure,
respectively. [optional]
text Text describing the error. This field ONLY may be in the
character set specified by the "charset" parameter of the body
part, if it is written using the "alternate charset" mechanism
of STIF. If the alternate charset mechanism is not used, or
if the charset parameter does not appear, the text must be in
US-ASCII. [optional]
tag Additional information which may be used by internetwork mail
gateways to allow mapping of DSNs to and from similar services
in other environments. The contents of the tag are defined by
the protocol used to request delivery reports. [optional]
6. Conformance and Usage Requirements
An MTA or gateway conforms to this specification if it generates DSNs
according to the format defined here. For MTAs and gateways that do not
K. Moore Expires 16 March 1994 [Page 4]
Delivery Status Notifications 16 September 1993
support requests for delivery notification (such as in [5]), it is
sufficient that delivery failure reports use this format.
An MTA or gateway should NOT generate "delivered", "relayed", or
"forwarded" DSNs unless specifically requested by the sender, via the
SMTP extension defined in [5] or some other MTA-level protocol.
MTAs and gateways should not use the "orig-rcpt" field of the
message/delivery-report content-type unless the mail transfer protocol
ensures that the address provided is that originally specified by the
sender of the message. (Ordinary SMTP does not make that guarantee; the
SMTP extension defined in [5] does.)
DSNs must be returned to the sender of the message, in such a way
that the notification itself will not "bounce" if delivery of the
notification fails. (In SMTP, this is accomplished by using an empty
string as the sender address in the MAIL command.)
This specification places no restrictions on the use of delivery
notifications by recipient user agents or distribution lists.
7. The message/rfc822-fragment content-type
The message/rfc822-fragment content-type is defined as follows:
MIME type name: message
MIME subtype name: rfc822-fragment
Required parameters: none
Optional parameters: none
Encoding considerations: any standard MIME content-transfer-
encoding may be used.
Security considerations: none
A message returned in a DSN may have been truncated for any of
several reasons. If such a message were packaged in a message/rfc822
content-type, a missing final boundary marker might confuse MIME mail
readers.
The message/rfc822-fragment content-type is used to label an RFC 822
(or MIME) message which may not be complete. Unlike a message/rfc822
content-type, the message/rfc822-fragment content-type is opaque to the
mail system. In general, mail handling software should not assume that
such a body part is well-formed according to either RFC 822 or MIME.
Gateways are specifically prohibiting from "taking apart" and
translating a message/rfc822-fragment message and performing operations
on its component parts. When necessary, a gateway may apply a content-
transfer-encoding to the entire contents of an unencoded
message/rfc822-fragment body part, but it must not attempt to perform
such transformations on the individual components of the body part.
K. Moore Expires 16 March 1994 [Page 5]
Delivery Status Notifications 16 September 1993
8. Security considerations
Delivery notifications may be forged as easily as ordinary Internet
electronic mail. User agents and automatic mail handling facilities
(such as mail distribution list expanders) that wish to make use of such
notifications, should take appropriate precautions to minimize the
potential damage from denial-of-service attacks.
9. References
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
USC/Information Sciences Institute, August 1982.
[2] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, UDEL, August 1982.
[3] Westine, A., Postel, J. "Problems with the Maintenance of Large
Mailing Lists.", RFC 1211, USC/Information Sciences Institute, March
1991.
[4] Borenstein, N., Freed, N. "Multipurpose Internet Mail Extensions",
RFC 1341, Bellcore, Innosoft, June 1992.
[5] Moore, K. "SMTP Service Extension for Delivery Reports", Internet
Draft "draft-moore-smtp-drpt-00.txt", 16 September 1993.
[6] Crocker, D. "Structured Text Information Format (STIF)", Internet-
Draft "draft-crocker-stif-00.txt", June 1993.
[7] Klensin, J., Freed, N., Rose, M., Stefferud, E., Crocker. D. "SMTP
Service Extensions." RFC 1425, United Nations University, Innosoft
International, Inc., Dover Beach Consulting, Inc., Network
Management Associates, Inc., The Branch Office, February 1993.
[8] Klensin, J., Freed, N., Moore, K. "SMTP Service Extension for
Message Size Declaration." RFC 1427, United Nations University,
Innosoft International, Inc., University of Tennessee, February
1993.
K. Moore Expires 16 March 1994 [Page 6]
Delivery Status Notifications 16 September 1993
10. Author's address
Keith Moore
University of Tennessee
107 Ayres Hall
Knoxville, TN 37996-1301
USA
email: moore@cs.utk.edu
K. Moore Expires 16 March 1994 [Page 7]
Delivery Status Notifications 16 September 1993
Appendix: Example delivery notification
From: postmaster@netlib2.cs.utk.edu
To: j.random.user@cs.utk.edu
Subject: delivery notification
Content-type: multipart/delivery-notification; boundary=xyzzy
MIME-Version: 1.0
--xyzzy
Content-type: text/plain; charset=us-ascii
Your mail message could not be delivered to some of the recipients
listed below. The message has been returned to you.
--xyzzy
Content-type: message/delivery-report;
id="<930624.AA09834@cs.utk.edu>";
returned-content="<0xffcc8090@netlib2.cs.utk.edu>"
< orig-rcpt: bogus.user@netlib2.cs.utk.edu; status: 550;
by: netlib2.cs.utk.edu; date: Thu, 24 Jun 1993 18:43:03 -0400;
action: failed; text: <bogus.user@cs.utk.edu>: no such user; >
< orig-rcpt: remote.user@netlib2.cs.utk.edu; by: netlib2.cs.utk.edu;
date: Thu, 24 Jun 1993 18:43:04 -0400; action: relayed;
text: next-hop MTA does not support delivery reports;>
< orig-rcpt: big-mailing-list@netlib2.cs.utk.edu; by: netlib2.cs.utk.edu;
date: Thu, 24 Jun 1993 18:43:07 -0400; action: delivered;
text: message sent to list recipients;>
< orig-rcpt: moore@netlib2.cs.utk.edu; by: netlib2.cs.utk.edu;
date: Thu, 24 Jun 1993 18:43:07 -0400; action: forwarded;
text: message forwarded to <moore@cs.utk.edu>;>
--xyzzy
MIME-Version: 1.0
Content-type: message/rfc822
Content-id: <0xffcc8090@netlib2.cs.utk.edu>
Received: by netlib2.cs.utk.edu; Thu, 24 Jun 1993 18:43:03 -0400
To: bogus.user@netlib2.cs.utk.edu, remote.user@netlib2.cs.utk.edu,
big-mailing-list@netlib2.cs.utk.edu, moore@netlib2.cs.utk.edu
From: j.random.user@cs.utk.edu
Date: Thu, 24 Jun 1993 18:42:09 -0400
Subject: quote
Message-id: <930624.AA09834@cs.utk.edu>
"Don't sweat it -- it's not real life. It's only ones and zeroes."
-- spaf
--xyzzy--
K. Moore Expires 16 March 1994 [Page 8]